A universal mobile telecommunication system (UMTS) is a European-type, third generation IMT-2000 mobile communication system that has evolved from a European standard known as Global System for Mobile communications (GSM). UMTS is intended to provide an improved mobile communication service based upon a GSM core network and wideband code division multiple access (W-CDMA) wireless connection technology. In December 1998, a Third Generation Partnership Project (3GPP) was formed by the ETSI of Europe, the ARIB/TTC of Japan, the T1 of the United States, and the TTA of Korea. The 3GPP creates detailed specifications of UMTS technology. In order to achieve rapid and efficient technical development of the UMTS, five technical specification groups (TSG) have been created within the 3GPP for standardizing the UMTS by considering the independent nature of the network elements and their operations. Each TSG develops, approves, and manages the standard specification within a related region. Among these groups, the radio access network (RAN) group (TSG-RAN) develops the standards for the functions, requirements, and interface of the UMTS terrestrial radio access network (UTRAN), which is a new radio access network for supporting W-CDMA access technology in the UMTS.
In the description hereafter, the following abbreviations will be used:
AM Acknowledged mode
AS Access Stratum
ASN.1 Abstract Syntax Notation.1
CQI Channel Quality Indicator
MAC Medium Access Control
MBMS Multicast Broadcast Multimedia Service
NAS Non Access Stratum
RRC Radio Resource Control
S-CCPCH Secondary Common Control Physical Channel
SRB Signaling Radio Bearer
TCTF Target Channel Type Field
TFC Transport format combination
TM Transparent mode
TPC Transmit power commands
UE User Equipment
UM Unacknowledged mode
FIG. 1 gives an overview of the UMTS network 100, including the UE 110, the UTRAN 120 and the core network (CN) 130. As shown in FIG. 1, a UMTS system 100 is generally composed of a UE 110, NodeB 122, RNC 124, 126, SGSN 131, MSC 132 and other nodes, with different interfaces therebetween, which will be explained in more detail.
The UTRAN 120 is composed of several RNCs 124, 126 and NodeBs 122, which are connected via the lub interface. Each RNC controls several NodeBs. Each NodeB controls one or several cells, where a cell is characterized by the fact that it covers a given geographical area on a given frequency. Each RNC is connected via the Iu interface to the CN 130, i.e. towards the MSC 132 (Mobile-services Switching Centre) entity of the CN and the SGSN 131 (Serving GPRS Support Node) entity. RNCs can be connected to other RNCs via the Iur interface. The RNC handles the assignment and management of radio resources and operates as an access point with respect to the core network.
The NodeBs receive information sent by the physical layer of the terminal (UE 110) through an uplink and transmit data to the terminal through a downlink. The Node-Bs operate as access points of the UTRAN for the terminal. The SGSN 131 is connected via the Gf interface to the EIR 133 (Equipment Identity Register), via the GS interface to the MSC 132, via the GN interface to the GGSN 135 (Gateway GPRS Support Node) and via the GR interface to the HSS 134 (Home Subscriber Server). The EIR hosts lists of mobiles (terminals) which are allowed or are not allowed to be used on the network. The MSC which controls the connection for CS services is connected via the NB interface towards the MGW 136 (Media Gateway), via the F interface towards the EIR 133, and via the D interface towards the HSS 134. The MGW 136 is connected via the C interface towards the HSS 134, and to the PSTN (Public Switched Telephone Network), and allows to adapt the codecs between the PSTN and the connected RAN.
The GGSN is connected via the GC interface to the HSS, and via the GI interface to the Internet. The GGSN is responsible for routing, charging and separation of data flows into different RABs. The HSS handles the subscription data of the users.
Other connections exist that are not important for the current invention.
The UTRAN 120 constructs and maintains a radio access bearer (RAB) for communication between the terminal 110 and the core network 130. The core network requests end-to-end quality of service (QoS) requirements from the RAB, and the RAB supports the QoS requirements the core network has set. Accordingly, by constructing and maintaining the RAB, the UTRAN can satisfy the end-to-end QoS requirements.
The services provided to a specific terminal (UE 110) are roughly divided into the circuit switched (CS) services and the packet switched (PS) services. For example, a general voice conversation service is a circuit switched service, while a Web browsing service via an Internet connection is classified as a packet switched (PS) service.
For supporting circuit switched services, the RNCs 124, 126 are connected to the mobile switching center (MSC 132) of the core network 130 and the MSC 132 is connected to the gateway mobile switching center (GMSC) that manages the connection with other networks. For supporting packet switched services, the RNCs are connected to the serving general packet radio service (GPRS) support node (SGSN 131) and the gateway GPRS support node (GGSN 135) of the core network. The SGSN supports the packet communications with the RNCs and the GGSN manages the connection with other packet switched networks, such as the Internet.
FIG. 2 illustrates a structure of a radio interface protocol between the terminal and the UTRAN according to the 3GPP radio access network standards. As shown in FIG. 2, the radio interface protocol has horizontal layers comprising a physical layer, a data link layer, and a network layer, and has vertical planes comprising a user plane (U-plane) for transmitting user data and a control plane (C-plane) for transmitting control information. The user plane is a region that handles traffic information with the user, such as voice or Internet protocol (IP) packets. The control plane is a region that handles control information for an interface with a network, maintenance and management of a call, and the like.
The protocol layers in FIG. 2 can be divided into a first layer (L1), a second layer (L2), and a third layer (L3) based on the three lower layers of an open system inter-connection (OSI) standard model. The first layer (L1), namely, the physical layer, provides an information transfer service to an upper layer by using various radio transmission techniques. The physical layer is connected to an upper layer called a medium access control (MAC) layer, via a transport channel. The MAC layer and the physical layer exchange data via the transport channel. The second layer (L2) includes a MAC layer, a radio link control (RLC) layer, a broadcast/multicast control (BMC) layer, and a packet data convergence protocol (PDCP) layer. The MAC layer handles mapping between logical channels and transport channels and provides allocation of the MAC parameters for allocation and re-allocation of radio resources. The MAC layer is connected to an upper layer called the radio link control (RLC) layer, via a logical channel. Various logical channels are provided according to the type of information transmitted. In general, a control channel is used to transmit information of the control plane and a traffic channel is used to transmit information of the user plane. A logical channel may be a common channel or a dedicated channel depending on whether the logical channel is shared. Logical channels include a dedicated traffic channel (DTCH), a dedicated control channel (DCCH), a common traffic channel (CTCH), a common control channel (CCCH), a broadcast control channel (BCCH), and a paging control channel (PCCH), or a Shared Control Channel (SCCH) and other channels. The BCCH provides information including information utilized by a terminal to access a system. The PCCH is used by the UTRAN to access a terminal.
For the purposes of MBMS additional traffic and control channels are introduced in the MBMS standard. The MCCH (MBMS point-to-multipoint Control Channel is used for transmission of MBMS control information, the MTCH (MBMS point-to-multipoint Traffic Channel) is used for transmitting MBMS service data. The MSCH (MBMS Scheduling Channel) is used to transmit scheduling information.
Logical channels can be divided into Control Channels (CCH) and Traffic Channels (TCH). The Control Channels (CCH) may include a Broadcast Control Channel (BCCH); a Paging Control Channel (PCCH); a Dedicated Control Channel (DCCH); a Common Control Channel (CCCH); a Shared Control Channel (SHCCH); an MBMS point-to-multipoint Control Channel (MCCH); and an MBMS Scheduling Channel (MSCH). The Traffic Channels (TCH) may include a Dedicated Traffic Channel (DTCH); a Common Traffic Channel (CTCH); and an MBMS point-to-multipoint Traffic Channel (MTCH).
The MAC layer is connected to the physical layer by transport channels and can be divided into a MAC-b sub-layer, a MAC-d sub-layer, a MAC-c/sh sub-layer, a MAC-hs sub-layer and a MAC-m sublayer according to the type of transport channel being managed. The MAC-b sub-layer manages a BCH (Broadcast Channel), which is a transport channel handling the broadcasting of system information. The MAC-c/sh sub-layer manages a common transport channel, such as a forward access channel (FACH) or a downlink shared channel (DSCH), which is shared by a plurality of terminals, or in the uplink the Radio Access Channel (RACH). The MAC-m sublayer may handle the MBMS data.
The possible mapping between the logical channels and the transport channels from a UE perspective is given in FIG. 3.
The possible mapping between the logical channels and the transport channels from a UTRAN perspective is given in FIG. 4.
The MAC-d sub-layer manages a dedicated channel (DCH), which is a dedicated transport channel for a specific terminal. The MAC-d sublayer is located in a serving RNC (SRNC) that manages a corresponding terminal, and one MAC-d sublayer also exists in each terminal. The RLC layer, depending of the RLC mode of operation supports reliable data transmissions and performs segmentation and concatenation on a plurality of RLC service data units (SDUs) delivered from an upper layer. When the RLC layer receives the RLC SDUs from the upper layer, the RLC layer adjusts the size of each RLC SDU in an appropriate manner based upon processing capacity and then creates data units by adding header information thereto. The data units, called protocol data units (PDUs), are transferred to the MAC layer via a logical channel. The RLC layer includes a RLC buffer for storing the RLC SDUs and/or the RLC PDUs.
The BMC layer schedules a cell broadcast (CB) message transferred from the core network and broadcasts the CB message to terminals positioned in a specific cell or cells.
The PDCP layer is located above the RLC layer. The PDCP layer is used to transmit network protocol data, such as the IPv4 or IPv6, efficiently on a radio interface with a relatively small bandwidth. For this purpose, the PDCP layer reduces unnecessary control information used in a wired network, a function called header compression.
The radio resource control (RRC) layer located at the lowest portion of the third layer (L3) is only defined in the control plane. The RRC layer controls the transport channels and the physical channels in relation to setup, reconfiguration, and the release or cancellation of the radio bearers (RBs). The RB signifies a service provided by the second layer (L2) for data transmission between the terminal and the UTRAN. In general, the set up of the RB refers to the process of stipulating the characteristics of a protocol layer and a channel required for providing a specific data service, and setting the respective detailed parameters and operation methods. Additionally the RRC handles user mobility within the RAN, and additional services, e.g. location services.
The different possibilities that exist for the mapping between the radio bearers and the transport channels for a given UE are not all possible all the time. The UE/UTRAN deduce the possible mapping depending on the UE state and the procedure that the UE/UTRAN is executing. The different states and modes are explained in more detail below, as far as they concern the present invention.
The different transport channels are mapped onto different physical channels. The configuration of the physical channels is given by RRC signaling that is exchanged between the RNC and the UE.
As for physical channels, the DPCH channel can be established and used simultaneously between the UE and one or several cells of one or several NodeBs as shown in FIG. 5.
This situation where the UE has a DPCH established simultaneously to several cells is called soft handover. The case where the UE has established a DPCH simultaneously to several cells of the same NodeB is called softer handover. For the DPCH the UE is always combining the TPC commands from all radio links in the downlink, and uses always the command, which asks for the least transmit power (i.e. in the case one radio link says Up and the other one Down the UE chooses to decrease the transmit power).
The RLC layer (Radio Link Control) is a layer 2 protocol which is used in order to control the data exchange between the logical channels between the RNC and the UE. The RLC layer can currently be configured in 3 types of transfer modes: Transparent mode; Unacknowledged mode; and Acknowledged mode.
The different functionalities that are available depend on the transfer mode.
In acknowledged and unacknowledged mode SDUs (service data unit) can be split into smaller PDUs (protocol data units) that are used for transmission over the air interface. The transmitter side separates the SDU into PDUs, and based on control information that is added to the PDUs the receiver side re-assembles the PDUs in order to reconstruct the SDUs. Such control information is e.g. a PDU sequence number in order to detect whether a PDU has been lost, or a Length Indicator (LI) which indicates the beginning/end of a SDU inside an RLC PDU.
In unacknowledged mode, the receiver does not send a confirmation to the transmitter of correctly received PDUs, but the receiver side just reassembles PDUs to SDUs based on signaling information contained in the PDUs and transfers the complete SDUs to higher layers.
In acknowledged mode, the receiver sends acknowledgements for the correctly received PDU. The transmitter uses these acknowledgements in order to initiate retransmissions of missing PDUs. The acknowledgements are sent in certain conditions. There are several mechanisms foreseen in order to initiate the transmission of the acknowledgements for PDUs received by the receiver. Which mechanisms are activated is defined in the standard and/or configured by RRC signaling. One example for such a mechanism for the transmission of a status PDU is e.g. the reception of a PDU with a sequence number that does not correspond to the latest received sequence number increased by one, or when the receiver receives an indication from the transmitter in the RLC control information that an acknowledgment (also called Status) should be sent. The indication of the transmitter to send a status PDU is called Polling.
When the transmitter sends a Polling bit, a mechanism is defined in the UMTS standard if no Status report has been received after the transmission of the polling after a certain time. This mechanism initiates the transmitter to retransmit a PDU including the polling indicator and is called a timer poll.
Another mechanism counts the number of retransmissions of a PDU. In the case the retransmission exceeds a certain number (MaxDat) the transmitter starts the reset procedure, which is a procedure that allows setting of the transmitter and the receiver entity of a radio bearer using AM RLC mode to an initial state. When the Reset procedure is initiated the initiating entity transmits a Reset PDU to the terminating entity. The terminating entity acknowledges the reception of the Reset PDU by transmitting the Reset Ack PDU. If the initiating entity has not received the Reset Ack PDU after a certain time the initiating entity retransmits the Reset PDU. If the initiating entity has not received an Reset Ack PDU after a certain amount of retransmissions the initiating entity detects an unrecoverable error.
This example describes the situation where a dysfunction is detected in the operation of an RLC entity in RLC AM mode. Other mechanisms to detect a dysfunction are possible, are already described in the UMTS standard, or possible to be imagined and implemented. It is also possible to imagine detection mechanisms for RLC entities in UM mode, which would e.g. detect that undefined signaling information is included in the RLC PDU, or where higher layers detect that the reception/transmission of the UM entity is not behaving correctly.
As explained in the above there are mechanisms defined in the standard, and other mechanisms can be imagined that detect an unrecoverable error, which can correspond to a blocked situation, or a situation where the communication is disturbed.
If the UE detects an unrecoverable error situation as described in the standard the UE enters CELL_FACH state and sends a Cell update message to the NodeB/RNC eventually indicating that an unrecoverable error has occurred by setting the IE (Information Element) Cell update cause to the cause RLC unrecoverable error. The UE indicates by including the IE AM_RLC error indication (RB2, RB3 or RB4) that this unrecoverable error has either occurred for one of the SRBs with the Ids 2, 3 or 4, or by including the IE AM_RLC error indication (RB>4) that this error has occurred for one of the RBs using RLC AM mode with Ids higher than 4. The RNC can then send the Cell Update Confirm message and indicate that the RLC entities for SRBs with the Ids 2, 3 and 4, or for the RBs with Ids higher than 4 that use RLC AM mode shall be re-established by setting the IE RLC re-establish indicator (RB2, RB3 and RB4) and/or the RLC re-establish indicator (RB5 and upwards) to True.
The UM/AM RLC entity is also responsible for handling of ciphering and deciphering. In order to do so the RLC entity in the transmitter and the receiver maintain a COUNT-C number, which is composed of a Hyper frame number (HFN) and the RLC sequence number. The COUNT-C value, together with other information is used as input to a mathematical function that generates a bitstring. This bitstring and the RLC PDU except the SN are combined by the logical XOR operation, which ensures the ciphering of the data part of the RLC PDU. The HFN value is incremented each time the RLC SN wraps around (i.e. when the RLC SN reaches its highest value and restarts from 0). In the case the receiver misses a certain number of SNs, or in the case the SN received has been altered during the reception it is possible that the COUNT-C in the receiver and the transmitter are desynchronized. In this case the receiver is not capable to decipher correctly the information received. The receiver can detect the dysfunction of the deciphering entity by different mechanisms which are not further described here, and which are not part of the invention.
Regarding the RRC states, the RRC mode refers to whether there exists a logical connection between the RRC of the terminal and the RRC of the UTRAN. If there is a connection, the terminal is said to be in RRC connected mode. If there is no connect ion, the terminal is said to be in idle mode. Because an RRC connection exists for terminals in RRC connected mode, the UTRAN can determine the existence of a particular terminal within the unit of cells, for example which cell or set of cells the RRC connected mode terminal is in, and which physical channel the UE is listening to. Thus, the terminal can be effectively controlled.
In contrast, the UTRAN cannot determine the existence of a terminal in idle mode. The existence of idle mode terminals can only be determined by the core network to be within a region that is larger than a cell, for example a location or a routing area. Therefore, the existence of idle mode terminals is determined within large regions, and, in order to receive mobile communication services such as voice or data, the idle mode terminal must move or change into the RRC connected mode. The possible transitions between modes and states are shown in FIG. 6.
A UE in RRC connected mode can be in different states, e.g. CELL_FACH state, CELL_PCH state, CELL_DCH state or URA_PCH state. Other states could be envisaged of course. Depending on the states the UE carries out different actions and listens to different channels. For example a UE in CELL_DCH state will try to listen (amongst others) to DCH type of transport channels, which comprises DTCH and DCCH transport channels and which can be mapped to a certain DPCH, DPDSCH, or other physical channels. The UE in CELL_FACH state will listen to several FACH transport channel, which are mapped to a certain S-CCPCH, the UE in PCH state will listen to the PICH channel and to the PCH channel, which is mapped to a certain S-CCPCH physical channel.
Regarding the reading of system information, the main system information is sent on the BCCH logical channel, which is mapped on the P-CCPCH (primary Common Control Physical Channel). Specific system information blocks can be sent on the FACH channel. When the system information is sent on FACH the UE receives the configuration of the FACH either on the BCCH that is received on P-CCPCH or on a dedicated channel. When system information is sent on the BCCH (i.e. via the P-CCPCH) then in each frame or set of two frames the SFN (System frame number) is sent which is used in order to share the same timing reference between the UE and the NodeB.
The P-CCPCH is always sent using the same scrambling code as the P-CPICH (primary common pilot channel), which is the primary scrambling code of the cell. Each channel uses a spreading code as commonly done in WCDMA (Wideband Code Division Multiple Access) systems. Each code is characterized by its spreading factor (SF), which corresponds to the length of the code. For a given spreading factor the number of orthogonal codes is equal to the length of the code. For each spreading factor the given set of orthogonal codes as specified in the UMTS system are numbered from 0 to SF-1.
Each code can thus be identified by giving its length (i.e. spreading factor) and the number of the code. The spreading code that is used by the P-CCPCH is always of a fixed SF (spreading factor) 256 and the number is always the number 1. The UE knows about the primary scrambling code either by information sent from the network on system information of neighbouring cells that the UE has read, by messages that the UE has received on the DCCH channel, or by searching for the P-CPICH, which is always sent using the fixed SF 256, the spreading code number 0 and which always transmits a fixed pattern.
The system information comprises information on neighbouring cells, configuration of the RACH and FACH transport channels, and the configuration of MICH and MCCH, which are channels that are dedicated channels for the MBMS service.
Each time the UE is changing the cell it is camping (in idle mode) or when the UE has selected the cell (in CELL_FACH, CELL_PCH or URA_PCH) state the UE verifies that it has valid system information. The system information is organized in SIBs (system information blocks), a MIB (Master information block) and scheduling blocks. The MIB is sent very frequently and gives timing information of the scheduling blocks and the different SIBs. For SIBs that are linked to a value tag the MIB also contains information on the last version of a part of the SIBs. SIBs that are not linked to a value tag are linked to an expiration timer. SIBs linked to an expiration timer become invalid and need to be reread if the time of the last reading of the SIB is bigger than this timer value. SIBs linked to a value tag are only valid if they have the same value tag as the one broadcast in the MIB. Each block has an area scope of validity (Cell, PLMN, equivalent PLMN) which signifies on which cells the SIB is valid. A SIB with area scope Cell is valid only for the cell in which it has been read. A SIB with area scope PLMN is valid in the whole PLMN, a SIB with the area scope equivalent PLMN is valid in the whole PLMN and equivalent PLMN.
In general, the UEs read system information when they are in idle mode, CELL_FACH state, CELL_PCH state or in URA_PCH state of the cells that they have selected/the cell that they are camping on. In the system information they receive information on the neighbouring cells on the same frequency, different frequencies and different RAT (Radio access technologies). This allows the UE to know which cells are candidates for cell reselection.
Regarding the delays in communication, the conventional art call setup procedure takes a relatively long time due to the different message exchanges shown in FIG. 7. Namely, FIG. 7 shows the distribution of the delays in the call setup procedure. The delay that needs to be imputed to the network is the delay between the reception of the uplink message and the transmission of the downlink message. The graph shows the times between the reception/transmission of the messages in the RRC layer of the UE, i.e. does not include the time that it takes to send the uplink messages via the RLC.
One part of the delay is due to the setup of the radio bearers. The delay between the transmission of the radio bearer setup and the radio bearer setup complete is mostly due to the activation time. The UE will only transmit the radio bearer setup complete message once the activation time has expired and the UE has synchronized on the new radio link.
FIG. 8 shows the synchronized radio bearer setup (reconfiguration) in more detail. In step 1, the procedure is initiated by the reception of a Rab assignment Request. Instead the procedure could be triggered by any other procedure. The steps 2 to 9 are related to the need to setup a new radio bearer, the allocation of the transport resources and the resources inside the NodeB. In step 10 the RNC decides on an activation time that is sent in the step 11 and 12 to the NodeB and the UE. The NodeB and the UE are then waiting for the activation time to be reached to switch to the new configuration in step 13a and 13b. In step 14 the UE confirms the successful reconfiguration to the RNC. The RNC indicates the successful completion of the reconfiguration.
The gray shaded region, where basically the UE and the NodeB are just waiting for the expiry of the activation time corresponds to delay introduced, which is wasted in the case that the procedure is successful. This delay is necessary in the case that the message on the UE needs to be retransmitted by RLC. Also in the case the UE wants to send a failure message on the old RL some minimum delay is needed in order to allow this message to go through, and evtl. to cancel the reconfiguration in the NodeB by a separate message from the RNC. Therefore a means for decreasing this delay in the case everything works well (no RLC retransmission, no failure message) is necessary.
FIG. 9 shows the unsynchronized radio bearer setup (reconfiguration) in more detail. In the case of the unsynchronized reconfiguration, the RNC initiates synchronously in step 2 the reconfiguration towards the UE indicating that the reconfiguration shall be applied immediately, and in step 4 towards the NodeB, also indicating that the reconfiguration shall be applied immediately. Because there is no means to control the delay before the UE/NodeB will apply the configuration there is a high risk that the UE will not be able to achieve synchronization on the new RL, and therefore will leave CELL_DCH state due to a physical channel failure.
FIG. 10 shows a hard handover procedure in more detail. Using a hard handover is already one possibility to avoid the activation time. In steps 1 to 10, the RNC establish on the NodeB a new independent configuration, with new transport resources for all transport channels. The NodeB tries to obtain synchronization to the UE by transmitting on the downlink with a fixed power that has been received form the RNC. In step 11, the UE receives the message to change the configuration used for the uplink and the downlink. In step 12, the UE tries to receive the downlink that is newly established and (optionally) starts to transmit in the uplink (depending whether the synchronization procedure A is used or not). The NodeB will detect that the synchronization of the old RL is lost, and that the synchronization with the new RL is gained, and report this to the RNC with the messages RL Link Failure for the old RL and RL Restore for the new Radio Links (step 13, 14). The RNC can then delete the old Radio Links (step 15, 16). The UE will indicate the successful Radio Bearer Setup Complete message (step 17), and the RNC can acknowledge the successful RAB setup to the CN (step 18).
The problem with this scenario is that this implies that during the reconfiguration the resources for the old and the new configuration are used. This wastes capacity on the air interface (two sets of DL spreading codes are reserved) in the NodeB, where the NodeB needs to decode two different UE configurations and in the transport, and the RNC.
Next, the aspects of uplink scrambling code, pilot pattern and synchronization will be considered.
The current CDMA systems use scrambling codes, spreading codes and pilot patterns in order to allow synchronization and the exchange of data blocks from different transport channels, which are coded and multiplexed together. In the UMTS system in the uplink the UE transmits a pilot pattern, which is spread with a spreading code as defined in the standard, and scrambled with a fixed complex scrambling code.
In the UMTS system the pilot pattern is sent on the DPCCH physical channel code and is time multiplexed with other DPCCH information e.g. the transmit power commands as shown in FIG. 11 for the DPDCH/DPCCH frame structure in the uplink.
The pilot pattern is sent at predefined time instants during each slot depending on the slot format chosen and is repeated at each frame. In the uplink, the PDCCH is sent always using the same spreading factor and spreading code. Therefore, the (time) instant where the pilot pattern is sent is always the same. In the case of compressed mode (i.e. when transmissions are interrupted e.g. in order to allow the UE to listen to a different frequency for doing measurements) the pattern (i.e. slot format) also changes.
FIG. 12 shows an example of how the generation of a signal in the uplink is performed.
The DPDCH on which the different transport channels are mapped is spread with a different spreading code (one or several spreading codes). The spreading factor used for the DPDCH can change dynamically from one TTI to the next one.
Since the pilot patterns have a specific sequence this allows that the NodeB calculates the timing of the UE transmission by correlating the received sequence with the expected sequence, shifted by different times T as shown in FIG. 13. This allows the NodeB to detect the timing of the uplink signal, and to verify whether the UE signal is contained in the received signal by comparing the absolute value of the sum of the complex value to a threshold. This is one way of doing, there are different ways, and the intention here is just to highlight that it is possible for the NodeB to check the timing of the uplink transmission, and to check whether the pilot sequence spread with a given spreading code and scrambled with a UE specific scrambling code is transmitted.
FIG. 13 shows an example of how detection of synchronization can be performed.
Now referring to FIG. 14, the concept of a Code Tree and Code Management will be considered. In the UMTS system the spreading codes of a length of 2n are used. These spreading codes can be generated out of a tree, which gives branches of orthogonal spreading codes. For each possible length of spreading codes there exists the number equal to the spreading factor of orthogonal codes. These codes are often grouped as a tree as shown in FIG. 14. All codes of the same spreading factor are orthogonal. The codes of different spreading factors are orthogonal in the case that the code with higher spreading factor is not part of the branch of the code with lower spreading factor. In the figure when the code of length 4 with number 0 is used the codes 0 and 1 of the length 8 cannot be used any more because they are not orthogonal, but the codes 2 and 3 of the length 8 can be used. If the code 1 of the length 2 is used the codes below in this branch cannot be used any more in parallel.
Next, the concepts of Downlink scrambling code, pilot pattern and synchronization will be considered.
In the downlink the DPCCH is time multiplexed with DPDCH and spread with the same spreading codes. Therefore the instants where pilot patterns are sent can vary depending on the spreading factor, and depending on the fact whether compressed mode is used or not.
FIG. 15 shows an example of how the generation of a signal in the downlink is performed.
Because the DPDCH is spread with the same spreading code as the pilot patterns and the other physical layer information (i.e. the DPCCH) each time the spreading factor changes the pattern with which the pilot bits and the TPC bits are sent, and the pattern with which the other physical channel information is sent is different. This means that in the case the new configuration includes a spreading factor different from the spreading factor before the reception of the DPCCH is not possible any more if the UE tries to receive a different spreading factor. The format of the DPCCH can also be changed during the reconfiguration without the changing the spreading factor.
The DPCH frame structure and its related DPCH timing characteristics will now be explained with reference to FIGS. 16 and 17.
FIG. 16 shows an example of the frame structure of the DPCH, and the structure of the DPCCH and the DPDCH that is transmitted.
FIG. 17 shows an example of DPCH timing. The DPCH, i.e. the timing of the DPDCH and DPCCH are offset compared to the Primary SCH. This means that the UE knows when the DPCCH is transmitted due to the parameter τDPCH that it has received from the network beforehand.
Regarding Transport Format Combination Indicators (TFCIs), in the UTRAN system different transport channels are mapped together on a Coded Composite Transport Channel (CCTrCH), which is mapped on a DPDCH. Each transport channel can apply different Transport Formats (TFs), each transport format including a distinct set of parameters. When different Transport channels are multiplexed together on a CCTrCH the combination of the different TFs of each transport channel indicates a Transport Format Combination, which allows the receiver and the transmitter to determine how the coding of the different transport channels is done. Therefore in order to decode the DPDCH the UE needs to know the TFC. There are different possibilities in the UTRAN standard:
In the case that the blind transport format detection is used the UE tries to decode the DPDCH with different TFC until the CRC code indicates that the information of all transport channels is received correctly. Alternatively the UTRAN can send the Transport Format Indicator, which is an indicator that signals the transport format combination of the different transport channels sent on the DPCCH.